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AMENDMENTS TO THE SPECIFICATION 

Please amend the specification as follows. 

On page 1 of the specification, please replace the paragraph beginning at line 13 with 
the following paragraph: 

This application further expressly incorporates by reference and makes a part hereof the 
following U.S. Patent Application Serial Nos. 10/040,887, 10/040,908 (published on July 10, 
2003 under Publication No. US-2003-0130624-A1), 10/059,929 (published on July 31, 2003 
under Publication No. US-2003-0141981-A1), the following U.S. Provisional Patent Application 
Serial Nos. 60/377,027, 60/376,625 and 60/376,655, and U.S. Patent No. 5,842,841. This 
application also expressly incorporates by reference and makes a part hereof the following U.S. 
Patent Applications : EIS 5909A,EIS 5909B,EIS 5909C,EIS 5909D,EIS 5909E,EIS 5909F, 
EIS 5909G, and EIS 5909H Application Serial Nos. 10/749,102, 10/748,762, 10/748,750, 
10/748,749, 10/749,099, 10/748,593, and 10/748,589 , which were all filed concurrently with the 
present application on December 30, 2003. 

On page 4 of the specification, please replace the paragraphs at lines 23 and 24 with 
the following paragraphs: 

FIGURE [[16a]] 16A is a view of an alarm/alert interface screen; 
FIGURE [[16b]] 16B is another view of an alarm/alert interface screen; 

On page 4 of the specification, please replace the paragraph at line 34 with the following 
paragraph: 

FIGURE [[25a]] 25A is a view of an allergies and height/weight interface screen; 

On page 5 of the specification, please replace the paragraphs at lines 1-2 with the 
following paragraphs: 

FIGURE [[25b]] 25B is a view of a medication history interface screen; 
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FIGURE [[25c]] 25C is a view of a lab results interface screen; 

On page 5 of the specification, please replace the paragraphs at lines 4-8 with the 
following paragraphs: 

FIGURE [[27]] 26A is another view of an interface screen of the medication delivery 
schedule process of FIGURE 26; 

FIGURE [[27a]] 27A is a view of an interface screen of a workflow infusion stop; 

FIGURE [[27b]] 27B is another view of an interface screen of a workflow infusion stop; 

FIGURE [[27c]] 27C is a view of an interface screen of a workflow to resume an 
infusion; 

On page 5 of the specification, please add the following paragraph at line 9: 
FIGURE 27D is another view of an interface screen of a workflow to resume an infusion; 

On page 5 of the specification, please replace the paragraph at line 21 with the 
following paragraph: 

FIGURE [[38a]] 38A is a view of another scan pump channel interface screen; 

On page 5 of the specification, please replace the paragraph at line 23 with the 
following paragraph: 

FIGURE [[39a]] 39A is another view of a comparison interface screen; 

On page 5 of the specification, please replace the paragraph at lines 29-30 with the 
following paragraphs: 

FIGURE [[45a]] 45A is a view of a communication loss interface screen; 
FIGURE [[45b]] 45 B is a view of a communication loss interface screen; 
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On page 6 of the specification, please replace the paragraph at line 2 with the 
following paragraph: 

FIGURE [[50a]] 50A is a view of a monitoring parameter entry interface screen; 

On page 7 of the specification, please replace the paragraph beginning at line 2 with 
the following paragraph: 

Turning to FIGURE 3, the patient care system 100 can include a plurality of medical 
devices 120. In one embodiment, the medical device is an infusion pump 120. Further, in 
another embodiment the medical device is a controller for an infusion pump. For ease of 
reference, this disclosure will generally identify the medical device of the system as an infusion 
pump, however, it is understood that the overall system 100 may incorporate any one or more of a 
variety of medical devices. Accordingly, as shown in FIGURE 3, a plurality of infusion pumps 
120 are connected to a hub or interface 107. As explained in detail further herein, the infusion 
pumps 120 can be of conventional design wherein each infusion pump 120 is associated with a 
patient. However, as will be appreciated by those having ordinary skill in the art, the infusion 
pumps 120 shown in FIGURE 3 do not have to be associated with the same patient or treatment 
location even though the infusion pumps are connected to the same hub 107. Moreover, each 
infusion pump 120 can be a single channel pump or a multiple channel pump, such as a triple 
channel pump. Any such channel is id e ntifi e d with r e f e r e nc e numb e r 121 . Typically, the pumps 
transmit messages containing pump status information on a periodic basis to the hub 107. A 
separate hub 107 can be used apart from the medical device 120 in order to centralize 
communications, for cost efficiencies, and/or to allow for retrofitting of existing medical devices 
that do not currently communicate with a central computer system 108 so that each such medical 
device can communicate with a central computer system 108. 

On page 13 of the specification, please replace the paragraph beginning at line 17 with 
the following paragraph: 

In one embodiment, the first central computer 109 can comprise a validated server, 
such as a Compaq DLG-380 with Windows 2003 Server OS, running Active Directory for 
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user and device authentication, Certificate Authority for issuance of server and client 
certificates, SQL Server 2000 for temporary data storage, Internet Information Server (IIS) for 
application hosting (Web Services and Web pages). The second central computer 108a can 
comprise a non-validated Server, such as an external Hospital Information System (HIS) 
Server connected through a dedicated Ethernet TCP/IP connection 103 accessing a data 
replication Web service exposed by the validated server at the other end of the dedicated 
connection. The second central computer 108a can alternatively comprise software for 
performing one or more of the various functionalities described in general herein, such as a 
pharmacy and other systems. Thus, the second central computer [[and]] can comprise these 
types of functions and have an interface with other systems, such as an external Hospital 
Information System (HIS) Server. 

On page 16 of the specification, please replace the paragraph beginning at line 17 with 
the following paragraph: 

The first central computer subsystem preferably consists of a server 109 with a software 
application loaded and configured for sending and receiving data to and from multiple hubs 107, 
multiple digital assistants 118, and the second central computer sub-system comprising [[sever]] 
server 108a. 

On page 16 of the specification, please replace the paragraph beginning at line 21 with 
the following paragraph: 

Turning to FIGURE 54, server 109 is preferably a COMPAQ DLG-380 with a 
MICROSOFT WINDOWS 2003 Server operating system 5414. In one embodiment, software 
components that are loaded within the memory of the first central computer 109 include a first 
central computer or server application 5412 within a NET framework 5416, an Active Directory 
Domain Service 5418 for users and device authentication, an SQL Server 5420 (show as a 
database) for temporary data storage, and Internet Information Server [[542]] 5422 (IIS) for 
application hosting. The NET framework 54 1 6 is preferably Microsoft NET framework 1 . 1 or 
greater wherein the NET framework connects the first central computer application 5412 to the 
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operating system, Internet Information Server 5422, SQL Database 5420, and Active Directory 
Domain Service 5418 components. As will be appreciated by those having ordinary skill in the 
art, the Active Directory Domain Service 5418 provides services utilized by the Windows Server 
Operating System 5414 and the first central computer application 5412 to assist in ensuring that 
only authentic and authorized hub subsystem, second central computer subsystem and users of 
the personal digital assistant subsystem have access to the first central computer and thus the first 
central computer application 5412. 

On page 18 of the specification, please replace the paragraph beginning at line 12 with 
the following paragraph: 

As shown in FIGURE 54, the incoming messages are routed via the Internet Information 
[[Sever]] Server and the NET framework components to the application 5412 loaded on the first 
central computer (i.e., server 109 of FIGURE 3). The first central computer application 5412 
utilizes the Active Directory Domain Service 5418 to verify that the second central computer 
message is authentic, processes the contents, and then stores the resulting data in the SQL server 
database component 5420. 

On page 1 8 of the specification, please replace the paragraph beginning at line 1 8 with the 
following paragraph: 

The application 5412 loaded on the first central computer then responds to the second 
central computer by issuing an HTTP response method that is routed via the NET framework 
component 5416 and internet information [[sever]] server component 5422 to the second central 
computer. This response message indicates the success or failure of the data transfer and 
processing. 

On page 21 of the specification, please replace the paragraph beginning at line 17 with the 
following paragraph: 

Accordingly, the RoutePDA incoming interface is utilized for communication with the 
web browser located in the PDA(s) 118. This interface receives incoming HTTP request 
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messages containing data encoded as name-value pairs consistent with the HTTP "GET" and 
"POST" protocols. The incoming messages are routed via the Internet Information [[Sever]] 
Server and the NET Framework component to the application 5412 loaded within the first central 
computer. The application 5412 loaded on the first central computer reroutes the incoming 
message to the second central computer utilizing the NET framework 5416 and the RoutePDA 
outgoing interface as discussed below. 

On page 23 of the specification, please replace the paragraph beginning at line 16 with the 
following paragraph: 

The incoming messages are routed via the Internet Information [[Sever]] Server and the 
Net framework components to the application 5412 loaded within the first central computer 
application. The first central computer application utilizes the Active Directory Domain Service 
component to verify that the hub subsystem message is authentic. The first central computer then 
processes the contents, and stores the resulting data in the SQL Server Database component. 
Finally, the first central computer application issues an HTTP response message to the sending 
hub device via the NET framework and Internet Information [[Sever]] Server components. This 
response messages indicated the success or failure of data transfer and processing. 

On page 27 of the specification, please replace the paragraph beginning at line 14 with the 
following paragraph: 

The infusion system 210, or healthcare system 210, within the [[patent]] patient care 
system 100 provides computerized prescribing and an electronic medical administration record 
(eMAR), among other things. Infusion system 210 puts charting, medication history, inventory 
tracking, and messaging at the clinician's fingertips. Patient care system 100 combines bar- 
coding and real-time technology to assist in ensuring that the right patient gets the right 
medication and the right dosage, at the right time, via the right route. Infusion system 210 
provides alerts, alarms, messages, and reminders such as, but not limited to, lab value, out of 
range, and missed dose. As part of the verification of the right dosage, the system can also 
provide verification of the settings of an infusion pump. 
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On page 38 of the specification, please replace the paragraph beginning at line 21 with the 
following paragraph: 

Any process descriptions or blocks in figures, such as [[FIGS.]] FIGURES 3-1 1, are to be 
understood as representing modules, segments, or portions of hardware, software, or the like, that 
can include one or more executable instructions for implementing specific logical functions or 
steps in the process, and alternate implementations are included within the scope of the 
embodiments in which functions can be executed out of order from that shown or discussed, 
including substantially concurrently or in reverse order, depending on the functionality involved, 
as would be understood by those having ordinary skill in the art. 

On page 39 of the specification, please replace the paragraph beginning at line 5 with the 
following paragraph: 

The medication management module 302 can coordinate the functions of the other 
modules in the patient care system 100 that are involved in the administration of medical 
treatment. The medication management module 302 generally coordinates with other portions of 
the patient care system 100. The medication management module 302 can include sub-modules 
for operating and/or interfacing with a CPOE, for operating and/or communicating with point-of- 
care modules, and for operating and/or communicating with medical treatment comparison 
modules. In FIGURE 4, an admissions, discharge, and transfer (ADT) interface 310, a billing 
interface 312, a lab interface 314, and a pharmacy interface 316 are shown. The ADT interface 
310 is used to capture information such as the patient's demographics, size, weight, and allergies. 
In a preferred embodiment, the ADT system utilizes an HL7 type of interface to transfer events 
that are entered into the hospital's ADT system into the second central server 108a. HL7 is a 
protocol for formatting, transmitting and receiving data in a healthcare environment. It provides 
interoperability between healthcare information systems through a messaging standard that 
enables disparate healthcare applications, such as a variety of different third-party applications, to 
exchange key sets of clinical and administrative data. Typically, in the present system 100, the 
HL7 ADT interface consists of three applications: the HL7 ADT server, the HL7 ADT client, and 
the HL7 ADT viewer. The pharmacy interface 316 imports orders from the pharmacy. The 
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pharmacy interface 316 can be an HL7-type of interface that interfaces with other systems for 
entering orders, such as a CPOE. This ability reduces the necessity for entering data into the 
patient care system 100 more than once. The pharmacy interface 316 can be configured to 
communicate with commercially available third-party systems such as, but not limited to Cerner, 
HBOC, Pyxis, Meditech, SMS, Phamous, and the like. A web services interface can provide near 
real-time coordination between Point of Care medication management systems supporting oral 
medication dosing such as McKesson AdminRx, Pyxis Verif5, etc. and infusion pump related 
medication management. Various other interfaces are also known to those having ordinary skill 
in the art, but are not shown in FIGURE 4. 

On page 42 of the specification, please replace the paragraph beginning at line 14 with the 
following paragraph: 

Clinician 116 identifies him/herself by scanning badge 1 16a, identifies the patient 1 12 by 
scanning wristband 1 12a, identifies the medication 124 by scanning medication label 124a, and 
identifies the medical device 332, such as infusion pump 120, by scanning label 120d. Clinician 
1 16 can also identify him/herself by providing a fingerprint and/or password as described above 
and shown in the login screen [[503]] 1903 of FIGURE 19. The medical device 332 can be a 
medical device capable of two-way communication with the medication management module 
302. Alternatively, the medical device 332 can only be capable of providing information to the 
medication management module 302. The infusion system 210 assists the clinician 116 in 
administering and verifying the medical treatment. In an alternate embodiment, the infusion 
system 210 can include downloading of operating parameters to the medical device 332. 
Clinician 116 can provide a visual verification to confirm the third copy 322 and/or the MAR 
matches the labeled medication 124. Scanner 338 can be used to enter machine readable 
information from the third copy 322 to the wireless device 330 and the medical device 332. 

On page 46 of the specification, please replace the paragraph beginning at line 20 with the 
following paragraph: 

Infusion order creation 504 includes functional blocks used to create infusion orders. 
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Infusion order creation 504 includes functions similar to those described in reference to 
prescription generation 304 (FIGURE 4). Infusion order creation 504 includes, but is not limited 
to, entering information 560, calculations 562, checks 564, and overrides [[568]] 566 . Infusion 
order creation is further described below in reference to FIGURE 8. The result of infusion order 
creation is an infusion order 702 (FIGURE 8). Infusion order 702 generally includes an infusion 
schedule 704 (FIGURE 8). 

On page 53 of the specification, please replace the paragraph beginning at line 27 with the 
following paragraph: 

FIGURE 8 is a block diagram showing functional components for infusion order creation 
504 of FIGURE 6. Infusion order creation 504 includes functional blocks for creating infusion 
orders. Infusion order creation 504 includes entering information 560, calculations 562, checks 
564, and overrides [[568]] 566. Entering information 560 can include functions such as, but not 
limited to, identifying the order type 560a, identifying the medications 560b, identifying the dose 
560c, identifying the diluent 560d, identifying the flow rate 560e, and identifying the infusion site 
560f. 

On page 55 of the specification, please replace the paragraph beginning at line 16 with the 
following paragraph: 

Calculations 562 can include calculations such as, but not limited to, bag quantity 
calculations 562a, translation calculations 562b, duration to volume calculations 562c, and flow 
rate to drip rate calculations 562d. Checks 564 include a variety of checks that an infusion order 
can be subject to. The checks include checks such as, but not limited to, a net concentration 
check 564a, a flow rate check 564b, an administration time check 564c, a duration check 564d, 
and an infusion site check 564e. If an infusion order fails a check 564, the clinician 1 16 may be 
able to override the check. Overrides [[568]] 566 can include overrides such as, but not limited 
to, a net concentration override [[568a]] 566a , a flow rate override [[568b]] 566b , an 
administration time override [[568c]] 566c , a duration override [[568d]] 566d, and an infusion 
site override [[568e]] 566e . Overrides [[568]] 566 can generate messages 520 for the physician 
and/or the pharmacy. The infusion system 210 can distinguish between system-wide and 
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subsystem overrides in determining whether it is necessary to generate a message 520. 

On page 55 of the specification, please replace the paragraph beginning at line 28 with the 
following paragraph: 

Overrides can include an indication of whether clinicians have the authority to override a 
tolerance. For example, flow rate override [[568b]] 566b can provide an indication of whether 
the clinician entering the infusion order has the authority to override the system flow rate 
tolerance 542b. This indication can apply to the patient care system 100 or a subsystem. 
Duration override [[568d]] 566d can provide an indication of whether the clinician 1 16 entering 
the infusion order has the authority to override the system duration 542d. This indication can 
apply to the patient care system 100 or a subsystem. Overrides 566 also include displaying of 
reasons for the override [[568f]] 566f . Reasons for the overrides [[568f]] 566f can be selected by 
the clinician 116 from drop-down menus. 

On page 60 of the specification, please replace the paragraph beginning at line 21 with the 
following paragraph: 

Modification changes 1002 include identifying a new duration 1002a, identifying a new 
flow rate 1002b, identifying a new infusion site 1002c, identifying a reason for a modification 
1002d, identifying the volume remaining in the infusion bag 1002e, and stop orders 516. The 
ordering options available during initial infusion order creation 504 are generally available for 
modifying the infusion order. Ordering options available during initial infusion order creation 
504 include those shown in FIGURE 8. Rechecks 1006 and recheck overrides 1008 are 
analogous to checks 564 and overrides 566 that are described in reference to FIGURE 8. New 
flow rate to new [[flow]] drip rate display 1010 assists the clinician and minimizes the possibility 
of errors during medication administration 512. The modified infusion order can lead to a 
modified infusion schedule. 
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On page 62 of the specification, please replace the paragraph beginning at line 20 with the 
following paragraph: 

Documentation 1012 captures infusion order information in real-time. Documentation 
includes documenting multiple infusions being administered at the same time and infusion 
modifications such as, but not limited to, duration changes [[1002a]] 1012a , flow rate changes 
[[1002b]] 1012b , volume changes 1012c, and infusion site changes [[1002d]] 1012d. 

On page 65 of the specification, please replace the paragraph beginning at line 12 with the 
following paragraph: 

While the present disclosure has focused on the use of infusion pumps 120 within the 
system 210, it is understood that other medical devices may be used within the system 210 
without departing from the scope of the present invention. For example, various types of medical 
devices include, but are not limited to, infusion pumps, ventilators, dialysis machines, etc. An 
additional type of medical device is a micro-electromechanical system (MEMS) component. 
MEMS is a technology used to create small or tiny devices which can be less than a millimeter in 
size , though they can also be larger as well . MEMS e l e m e nts devices are typically fabricated 
from glass wafers or silicon, but the technology has grown far beyond its origins [[in]] of the 
semiconductor industry. Each MEMS device is an integrated micro-system on a chip that can 
incorporate moving mechanical parts in addition to optical, fluidic, electrical, chemical and 
biomedical elements. The r e sulting MEMS compon e nts Resulting MEMS devices or elements 
are responsive to many types of input, including pressure, vibration, chemical, light, and 
acceleration. The MEMS components can be a number of different elements including various 
types of pumps, a flow valve, a flow sensor, tubing, a pressure sensor or combinations of 
elements. 

On page 65 of the specification, please replace the paragraph beginning at line 26 with the 
following paragraph: 

Accordingly, as explained in further detail below, one use of a MEMS component is as an 
in-line MEMS pump 5314, shown schematically in FIGURE 53. The MEMS pump 5314 is 
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capable of pumping fluid contained in the IV bag 5320 through the tube 5312, out through the 
access device 5324, and into a patient. The MEMS component has a MEMS local electronics 
element attached thereto, and the MEMS electronics element connects with an external, durable 
MEMS controller, which can communicate with the present system 210 as does the present 
infusion pump 120 described herein. In one embodiment of a MEMS pump 5314, the MEMS 
electronics element 5332 is embedded therein and can preferably store MEMS parametric 
operational information. The MEMS controller, with its electronics and power source, may be 
physically or wirelessly connected to the MEMS electronics element. In one embodiment, the 
parametric operational information may be loaded from the detachable MEMS controller 5338. 
Preferably, the pump element 5314 generates the fluid flow through a tube 5312 based on 
information stored locally within the MEMS electronics 5332. This information is preferably 
downloaded from a wired but detachable MEMS controller 5338. Further, the MEMS 
components may communicate with the system 210 via wireless communication. Additionally, 
the MEMS controller may provide a transfer of information to and from the system 210 to fully 
automate the control and interrogation of the MEMS components in the present system 210 
through a wireless or wired communication path. 

On page 72 of the specification, please replace the paragraph beginning at line 29 with the 
following paragraph: 

A patient information menu interface screen 2521, shown in FIGURE 25, is also available 
on the present system. The patient information menu screen 2521 provides a mini patient chart 
for the selected patient. The patient menu screen 2521 also provides the clinician 1 16 the ability 
to link to items relating to the patient, such as: administer medications/infusions, stop infusion, 
resume infusion, titrate infusion, flow rate history, pump status, and remove patient from shift. 
The patient menu screen 2521 also has tabs for: Allergies and Ht/Wt, Medication History, and 
Lab Results. An example of an Allergies & Ht/Wt interface screen 2521a is provided in FIGURE 
[[25a]] 25A. Typically this screen 2521a is displayed when the mini-chart is first opened. It 
displays information about the patient's drug and general allergies, and the last recorded height 
and weight of the patient. An example of a Medication History interface screen 2521b is 
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provided in FIGURE [[25b]] 25B. Typically, this screen 2521b provides the clinician with a 
medication history of the patient within the selected look back period. The look back period may 
be adjusted by the clinician. Finally, an example of the lab results interface screen 2521c is 
provided in FIGURE [[25c]] 25C . Lab results are made available in the system 210 through a lab 
interface. All available results are shown, and displayed in reverse chronological order. 

On page 73 of the specification, please replace the paragraph beginning at line 1 1 with the 
following paragraph: 

An infusion schedule interface screen 2623 for a patient is shown in FIGURE 26. This 
screen 2623 illustrates an infusion schedule for the selected patient. By clicking one of the 
identified orders, such as order 2625 for Morphine Sulfate on the infusion schedule screen 2623, 
the system 210 will link to the medication order interface screen 2627 shown in FIGURE [[26a]] 
26 A . Medication order screen 2627 provides a detail of order 2625 for the specified order (i.e., 
Morphine Sulfate). As part of the detailed order 2625, the therapy parameters 2629 are provided, 
as well as any warnings 2631 and the ability to link to additional information 2633. 

On page 75 of the specification, please replace the paragraph beginning at line 20 with the 
following paragraph: 

Next, the clinician 116 can select the pump channel mode as shown in the interface screen 
3881 of FIGURE 38. In the pump channel mode interface screen 3881, the therapy 3882 is 
shown and the clinician 116 has the option to designate the therapy 3882 as a primary therapy 
3884 or a piggyback therapy 3883. Each channel of the pump has the ability to operate a primary 
therapy in addition to a piggyback therapy. After the pump channel mode has been selected, the 
clinician can conduct a pump channel scan. FIGURE [[38a]] 38A illustrates a pump channel scan 
interface screen 3885. In the pump scan screen 3885, the clinician 1 16 scans the medical device, 
such as by scanning a bar code corresponding to the pump channel 121 and then clicking on the 
arrow key 4809. 
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On page 75 of the specification, please replace the paragraph beginning at line 29 with the 
following paragraph: 

After the clinician 1 16 has: (a) scanned the patient, such as on interface screen 2313 of 
FIGURE 23, (b) scanned the medication, such as on interface screen 3465 of FIGURE 34, and (c) 
scanned the pump channel, such as on interface screen 3885 of FIGURE [[38a]] 38A, the 
clinician 116 can program the infusion pump and conduct a comparison of the programmed 
infusion pump parameters or settings to the parameters of the pharmacy order. 

On page 78 of the specification, please replace the paragraph beginning at line 24 with the 
following paragraph: 

An example of a resultant comparison interface screen 3987 where the comparison results 
in a match is shown in FIGURE [[39a]] 39A, and identified at block 5226 in FIGURE 52. In this 
instance, if the pharmacy prescription parameters and the programmed pump channel settings 
match, the clinician 116 is instructed to start the infusion pump 120. 

On page 79 of the specification, please replace the paragraph beginning at line 17 with the 
following paragraph: 

After the infusion pump has initiated a therapy, the clinician 1 16 is able to view on his/her 
digital assistant 118 the status of the pump in a pump status interface screen 4391 as shown in 
FIGURE 43. The pump status display 4391 displays a list of all currently active infusions for a 
given patient. Typically, one of five icons will be displayed in conjunction with an infusion in 
this screen: infusion running indicator 4807, infusion standby indicator [[4809]] 4810 , infusion 
stopped indicator 4811, an unknown icon, and a delay icon. The pump status display [[591]] 
4391 does not update in real-time while a current screen is being displayed; however, by tapping 
the refresh button 4819, the most current real-time pump status screen will be displayed. 

On page 80 of the specification, please replace the paragraph beginning at line 22 with the 
following paragraph: 

Before administering a medication, the clinician 116 may be prompted to enter a 
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monitoring parameter, e.g., a heart rate before administering dioxin, or a pain assessment before 
administering morphine. When a monitoring parameter is associated with a medication, each 
administration of the medication displayed on the digital assistant 1 18 has a link to an interface 
screen where the clinician 116 may enter a value. An example of such an order having a link 
5001 to the entry of a monitoring parameter is shown in the order displayed in FIGURE 50. After 
the monitoring parameter link 5001 is selected, a monitoring parameter entry interface screen 
5003, as shown in FIGURE [[50a]] 50A is displayed. There, the clinician 116 may enter into the 
system 210 the requested information. 

On page 8 1 of the specification, please replace the paragraph beginning at line 7 with the 
following paragraph: 

As circumstances require, a clinician may stop a running infusion before it has finished. 
This may be done either with or without a discontinue order in the system to stop the infusion. 
Infusions that have been stopped may be resumed as circumstances require, such as titrating an 
order. When the discontinued infusion 48 1 3 and running infusion icons 4807 are both displayed 
on the digital assistant 118, the clinician 1 16 is instructed to navigate on the digital assistant 1 18 
to display a list of all running infusions for the patient. An example of such a discontinue 
infusion interface screen 2727a is provided in FIGURE [[27a]] 27A. In FIGURE [[27a]] 27A the 
discontinued infusion order will be highlighted and indicated as being a discontinued infusion 
order. The clinician 116 will then scan the bar code on the solution container for the discontinued 
infusion, and then scan the patient's ID. Next, interface screen 2727b is provided on the 
clinician's digital assistant 1 18 as shown in FIGURE [[2727b]] 27B. In interface screen 2727b 
the clinician can enter the time the infusion has been stopped, as well as the reason for stopping 
the infusion. The clinician 116 can then physically stop the infusion pump 120 by depressing the 
stop button on the infusion pump 120. 

On page 8 1 of the specification, please replace the paragraph beginning at line 21 with the 
following paragraph: 

A resume infusion interface screen 2727c is provided in FIGURE [[27c]] 27C . Infusions 
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that are recorded as stopped, without an order to discontinue, may be resumed. To resume an 
infusion the clinician 1 16 must initially navigate to the appropriate interface screen on the digital 
assistant 118. By tapping on the stopped infusion icon 4811 in the patient menu, a list of all 
infusions currently stopped for the patient will be displayed as shown in interface screen 2727c of 
FIGURE [[27c]] 27C . A prompt is provided for the clinician to select the infusion to be resumed. 
The clinician 116 then scans the bar code on the solution container for the infusion to be 
resumed. The system 210 compares the scanned ID to those for the infusions currently stopped 
for the patient. After the system 210 compares the ID with those that are currently stopped for the 
patient, the digital assistant 118 prompts the clinician 1 16 to scan the patient's ID. The system 
210 then confirms that the scanned ID matches the patient's ID, and the system 210 will display 
on the digital assistant 1 1 8 the description of the scanned infusion and prompt the clinician 1 16 to 
select a facility-defined reason for resuming the infusion, as shown in interface 2727d of FIGURE 
[[27d]] 27D . Once the reason is selected, the clinician 1 16 can restart the infusion at the pump 
120 and then tap the arrow 4809 to continue. The system 210 records the infusion as having been 
resumed. 

On page 82 of the specification, please replace the paragraph beginning at line 3 with the 
following paragraph: 

As shown in the various screen shots/interfaces for the digital assistant 1 18, a variety of 
icons are utilized to assist the clinician 116. Many of these icons are shown in FIGURE 48. The 
patient list button 4801 is a key that, when tapped, allows the clinician 1 16 to navigate directly to 
the patient list screen, such as the patient list screen 23 13 shown in FIGURE 23. The back button 
4803 is a key that, when tapped, returns the screen on the digital assistant 118 to the previous 
screen. The OK button 4805 is tapped to acknowledge data shown on the digital device 118. 
When the OK button 4805 is tapped the next screen is usually displayed. The infusion running 
indicator button 4807 indicates that a programmed infusion is now running for the selected pump 
120 and channel. The infusion standby indicator [[4809]] 4810 indicates that a programmed 
infusion has been put on standby for the selected patient, pump 120 and channel. The infusion 
stopped indicator 48 1 1 indicates that the programmed infusion has been stopped for the selected 
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patient, pump 120 and channel. The infusion discontinue order indicator 4813 indicates that a 
pharmacy-entered order will discontinue an infusion for the selected patient, pump 120 and 
channel. The physician's notes indicator 4815 indicates the presence of physician's notes for the 
selected patient, pump 120 and channel. The clinician 1 16 can tap the notes indicator 4815 to 
view the notes. The compare button 4817 is provided in various screens, and when tapped has 
the system 210 perform a comparison of the scanned item with the pharmacy-entered order, as 
well as additional comparisons. The refresh button 4819 is tapped to update and show the latest 
data on the screen. The exit button 482 1 allows the clinician to exit the current screen, and return 
to the previously displayed screen. The enter button 4809 is also the OK button and is tapped to 
acknowledge and enter either data selected from choices within a drop-down list, or data 
manually entered in a field. The comparison match indicator 4823 indicates that programmed 
pump settings match pharmacy-entered order information. The comparison mismatch indicator 
4825 indicates that programmed pump settings do not match pharmacy-entered order information. 
The cannot compare indicator 4827 indicates that the system cannot compare the programmed 
pump settings to the pharmacy-entered order information. The pump alarm/alert indicator 4872 
indicates that an alarm or alert condition is occurring. When the alarm/alert indicator 4872 is 
tapped, an expanded pump alarm and alert screen is displayed. On the alarm and alert screen, a 
red alarm/alert icon 4872 indicates an alarm condition, and a yellow alarm/alert icon 4872 
indicates an alert condition. The alarm/alert silence button [[3074]] 4874 is tapped to temporarily 
silence the audible alert on the digital device 1 18. The loss of communication indicator 4833 
indicates that the pump 120 and/or the hub 107 is not properly communicating with the system 
210. A message accompanying this indication describes the steps to take to resolve the problem. 
The wireless module low battery alert indicator 4835 indicates that the hub 107 is presently 
running on a backup battery that has less than 30 minutes of battery power remaining. 

On page 85 of the specification, please replace the paragraph beginning at line 17 with the 
following paragraph: 

As explained above, one type of notification is an alarm/alert notification. In the present 
system, notifications may be escalated. A specific alarm/alert escalation process is shown in 
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FIGURE 15. Typically, a notification process is provided to transmit notifications to any number 
of clinicians 1 16. The identified alarm/alert escalation process 1500 of FIGURE 15 provides for 
notifying a series of clinicians via a clinician device 118 when an alarm or alert is active on a 
medical device such as an infusion pump 120. In a preferred embodiment, the clinician's device 
is a personal digital assistant ("PDA") 118, such as shown in [[FIGS.]] FIGURES 1 and 3, 
typically having a display 118a and an audible tone or sound generator 118c. For illustrative 
purposes only, the clinician' s device will hereinafter be identified in this detailed description as a 
digital assistant 118. Further, the alarm/alert escalation process 1500 provides an escalation 
process when the clinician fails to respond to the alarm/alert notification on the digital assistant 
118. When an escalation process is started, a notification is provided to another or second 
clinician's digital assistant 118 as specified in the escalation procedure. While the alarm/alert 
notification is sent to the digital assistants 1 1 8, it is understood that typically the pump alarms and 
alerts can only be resolved at the pump. As explained herein, silencing of the alarm or alert at the 
digital assistant 1 18 , such as in block 1580 of FIGURE 15, may or may not affect the pump. 

On page 87 of the specification, please replace the paragraph beginning at line 13 with the 
following paragraph: 

The signal is received by the clinician's digital assistant 118, and subsequently displayed 
at block 1530 in FIGURE 15. This block provides for indicating the alarm or alert condition on 
the clinician's digital assistant 118. The indication on the clinician's digital assistant may be 
visual, audible, or both visual and audible. Further, the visual indication may include one or 
more of text, icons, symbols, etc. Similarly, as explained above, the audible indication may 
include a variety of audible tones at a variety of decibel levels. The visual and audible indicators 
are configurable by the hospital. FIGURE [[16a]] 16A discloses an exemplar screen shot of an 
alarm/alert interface list screen 1662a on the clinician's digital assistant 118. The alarm/alert list 
interface 1662a contains a list of patients that are currently associated to active channel 
alarm/alerts. As shown in FIGURE [[16a]] 16A, this clinician's digital assistant 118 currently 
has three active alarm/alert indications. There is an alarm condition for patient one 1664, an 
alarm condition for patient two 1666, and an alert condition for patient three 1668. Each patient 
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name and corresponding alarm/alert icon is a hyperlink to the appropriate pump alarm details 
interface screen, as shown in FIGURE 17. In one embodiment, the list of patients is filtered to 
only include the patients that are currently associated to the clinician 1 16 logged into the digital 
assistant 118 displaying this interface screen. This clinician-to-patient association can be as a 
primary clinician or as a temporary coverage clinician. A secondary clinician can also be 
accessed through the escalation process. The alarm/alert list interface 1662 is typically accessed 
by clicking on an alarm/alert icon 4872 displayed on the clinician's 116 digital assistant 118 
during normal clinician workflow. 

On page 87 of the specification, please replace the paragraph beginning at line 33 with the 
following paragraph: 

As explained above, when the alarm or alert condition is indicated on the clinician's 
digital assistant at block 1530, this indication may be provided visually, audibly or both. When 
an audible indication is provided at the clinician's digital assistant 118, the alarm icon 4872 
appears on the display 118a of the clinician's digital assistant 118. If an audible indication is 
provided, the clinician may have the ability to mute the audible indication even though the 
clinician has not responded to the alarm or alert condition. If the clinician does silence the alarm, 
the server 109 will initiate a silence timer. The visual indication will remain even though the 
audible indication has been muted. As shown in FIGURE [[16a]] 16A, if an alarm/alert would be 
providing an audible indication at the clinician's digital assistant 1 18 but for the muting by the 
clinician, a muted alarm/alert icon 4874 is provided. Further, upon escalation of the alarm/alert 
condition, if the clinician does not respond to the alarm within the timer limit, the muting of the 
audible indication may be disengaged. An alternate embodiment of the audible indication may be 
a vibration alert. 

On page 88 of the specification, please replace the paragraph beginning at line 12 with the 
following paragraph: 

Further, it is understood that multiple alarm/alert conditions may occur simultaneously or 
in overlapping periods. Accordingly, simultaneous or overlapping signals containing data 
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relating to the specific alarm or alert condition are generated and sent at block 1510 from the 
medical device 120, to the server 109. The alarm/alert signals may originate from the same or 
different medical devices 120. Further, the alarm/alert signals may relate to the same or different 
patients. Each of the alarm/alert signals, however, [[are]] is individually routed in the alarm/alert 
escalation process 1500 as herein described for an individual alarm/alert condition. As shown in 
FIGURE [[16a]] 16A, a specific clinician may have numerous alarm/alert indications on his/her 
digital assistant 118. Another example of an alarm/alert screen is shown on interface screen 
1662b of FIGURE [[16b]] 16B . As is typical in the present system, the line referenced as 1676 in 
interface screen 1662b of FIGURE [[16b]] 16B indicates the end of a list, and specifically the 
alarm/alert indication list for a specific clinician in this interface. 

On page 88 of the specification, please replace the paragraph beginning at line 24 with the 
following paragraph: 

FIGURE 17 illustrates a detailed patient alarm/alert interface 1765 after the clinician has 
selected to view one of the alarm/alert indications for the patient hyperlink on the clinician's 
digital assistant 1 18 from the interface list 1662a of FIGURE [[16a]] 16 A . Here, the clinician has 
selected the alarm indication for patient one 1664. The alarm/alert detail screen 1765 provides 
the clinician with a message detailing the reason for the alarm/alert. The clinician can click on 
the refresh button 4819 to update the current information displayed on the screen 1765. As 
shown on interface 1867 of FIGURE 18, multiple alarms or alerts 1878, 1882 may exist for the 
same patient. This alarm/alert interface 1867 provides a list of all active pump alarm/alerts that 
are currently associated to a given patient. These active pump alarm/alerts can be from multiple 
channels 121 and/or pumps 120, and even spread across multiple hubs 107. This interface screen 
1867 is accessed by specifying a given patient on the pump alarm list screen 1662. 

On page 89 of the specification, please replace the paragraph beginning at line 17 with the 
following paragraph: 

When an alarm is escalated, the server 109 conducts another precondition check at block 
[[155511 1550 . This precondition check [[1555]] 1550 may include: associating the patient with a 
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secondary clinician (this association may be conducted at the central system servicing unit 108a); 
and, associating the second clinician with that clinician's digital assistant 1 18, also referred to as 
the second clinician's device or second clinician's digital assistant 118. The server 109 uses the 
information gained in its precondition check at block [[1555]] 1550 to establish a relationship 
between the medical device 120, the patient, the secondary clinician and the second clinician's 
digital assistant 118. 

On page 89 of the specification, please replace the paragraph beginning at line 25 with the 
following paragraph: 

Following the second precondition check at block [[1555]] 1550 , the server 109 may also 
determine if the second clinician's digital assistant 1 18 is active. If the second clinician's digital 
assistant 118 is active, then the server 109 generates an escalated signal representative of the 
alarm or alert condition that exists. The escalated signal similarly includes data such as the 
patient's name, patient's location, room identification, bed identification, alarm or alert type, 
condition description, time, date, clinician identification and/or prescription. In the preferred 
embodiment, the escalated signal is transmitted from the server 109 to the wireless access point 
1 14. The wireless access point 1 14 then transmits the escalated signal relating to the alarm or 
alert condition via a wireless communication transmission to the second clinician's digital 
assistant 118 at block 1555. 

On page 90 of the specification, please replace the paragraph beginning at line 24 with the 
following paragraph: 

Referring back to block 1520, if the server 109 determines that the primary clinician's 
digital assistant 118 is not active, and if at block 1545 the server 109 determines that the 
alarm/alert condition still exists, the server 109 will proceed to block 1550 as discussed above to 
determine the appropriate secondary or charge clinician to send the alarm/alert signal. 
Additionally, it is understood that block 1520 may occur at any at any time during the alarm/alert 
escalation process 1500. One reason for a clinician's digital assistant 1 18 being inactive could be 
a loss of a signal from the server 109. As shown in the communication loss interface screen 4501 
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of FIGURES [[45a]] 45A and [[45b]] 45B, when the signal is lost the digital assistant 118 will 
provide the clinician 1 16 with a screen 4501, and/or an audible/vibratory indication, indicating a 
lost signal. The communication loss screen 4501 also informs the clinician 116 as to which 
patients the signal has been lost. At screen 4501 the system 210 also provides the clinician 116 
with trouble shooting tips to regain a signal. When a hub 107 or digital assistant 1 18 is outside of 
the wireless range, pump alarms and alerts cannot be received at the digital assistant 118. 

On page 91 of the specification, please replace the paragraph beginning at line 4 with the 
following paragraph: 

Other reasons for the digital assistant 118 being inactive could be the loss of battery 
power at the digital assistant 1 18, a loss of battery power at the wireless hub 107, or the digital 
assistant losing a signal with the access point 1 14. The system 210 does provide the clinician 1 16 
with a low battery screen. As shown in interface screen 4603 of FIGURE 46, one type of low 
battery screen is a screen to alert the clinician that a low battery situation exists on a wireless hub 
107 connected to a patient's infusion pump. When a low battery screen is provided, the screen 
contains a list of patients for which infusions are associated with that specific hub 107. The list 
of patients is generally filtered to include only the patients that are currently associated to the 
clinician logged into the digital assistant 1 18 displaying the screen 4603, and also all patients that 
share the same infusion pump 120/hub 107 with the logged-in clinician. This clinician-to-patient 
association can be as a first clinician or as a secondary clinician through the escalation process. It 
is understood that other reasons for the clinician's digital assistant 118 being inactive are 
possible. Nevertheless, if at any time the clinician's digital assistant 118 becomes inactive, the 
process 1 500 may proceed to block [[3 100]] 1550 such that the signal may be sent to a secondary 
clinician and/or to the charge clinician. Further, as explained above with respect to a time-out 
feature and other features of this disclosure, if a communication signal is lost from either the 
server 109 or the medical device 120, a signal lost message may be provided on the digital 
assistant 1 18 as shown in FIGURES [[45a]] 45A and [[45b]] 45B. 
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On page 9 1 of the specification, please replace the paragraph beginning at line 3 1 with the 
following paragraph: 

The server 109 records all alarm/alert conditions as an event at block 1585. Recording 
the event may include: recording information on the alarm/alert condition; recording the clinician 
who responded to the alarm/alert condition; recording the initial time of the alarm/alert condition 
(see block 1505); and, recording the time when the alarm/alert condition was rectified. 
Additionally, at block 1590, the server 109 will reset the timer and update [[an]] a medical device 
alarm list. The alarm/alert condition may also be recorded in the pump's event history. 

On page 109 of the specification, please replace the paragraph beginning at line 19 with 
the following paragraph: 

If the channel is not running, the first central server 109 causes the digital assistant 1 18 to 
display a "continue overwrite" warning message indicating that a different patient 112 is 
associated with the scanned channel, but the channel is not currently running at block 5916. 
Preferably, the warning message indicates that continuing will overwrite existing data (e.g., 
remove the association with the other patient 1 12). The warning message may also include data 
indicative of the patient 112 that is associated with the scanned channel (e.g., patient's name), the 
primary medication 124, and/or the piggyback medication 124. Preferably, the user is given the 
option to cancel, rescan, or continue. If the user chooses to cancel the operation, the first central 
server 109 sends a cancel code to the second central server 108a via the cancellation URL at 
block 5908. If the user chooses to rescan, the first central server 109 causes the digital assistant 
1 1 8 to display the screen prompting the user to scan a machine-readable identifier associated with 
the channel at block 5902. If the user chooses to continue, the first central server 109 causes the 
digital assistant 1 18 to display a message indicting indicating that it is okay to use the selected 
channel at block 5918. When the user presses "continue" the first central server 109 returns 
control to the current action (e.g., administer, channel change, etc.) without issuing additional 
displays to the digital assistant 1 18. 
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On page 1 10 of the specification, please replace the paragraph beginning at line 1 with the 
following paragraph: 

If a valid patient identifier is present in the database, and the two patient identifiers do 
match (i.e., the channel is assigned to this patient 1 12) at block 5920, the first central server 109 
checks the database to see if the channel is empty (e.g., no primary or piggyback infusion 
associated with this channel) at block 5922. If the channel is empty, the first central server 109 
causes the digital assistant 1 18 to display the message indicting indicating that it is okay to use 
the selected channel at block 5918. If the channel is not empty, the first central server 109 checks 
the database to see if the channel is running (in either primary and/or piggyback mode) at block 
5924. 

On page 1 10 of the specification, please replace the paragraph beginning at line 19 with 
the following paragraph: 

If the channel is not running, the first central server 109 causes the digital assistant 1 18 to 
display a "continue" message indicating that this patient 112 is associated with the scanned 
channel, but the channel is not currently running at block 5928. The message may also include 
data indicative of the patient 112 (e.g., patient's name), the primary medication 124, and/or the 
piggyback medication 124. Preferably, the user is given the option to cancel, rescan, or continue. 
If the user chooses to cancel the operation, the first central server 109 sends a cancel code to the 
second central server 108a via the cancellation URL at block 5908. If the user chooses to rescan, 
the first central server 109 causes the digital assistant 118 to display the screen prompting the 
user to scan a machine-readable identifier associated with the channel at block 5902. If the user 
chooses to continue, the first central server 109 causes the digital assistant 118 to display a 
message indicting indicating that it is okay to use the selected channel at block 5918. When the 
user presses continue again, the first central server 109 returns control to the current action (e.g., 
channel change) without issuing additional displays to the digital assistant 1 18. 
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On page 1 16 of the specification, please replace the paragraph beginning at line 7 with the 
following paragraph: 

When the user selects the "resume infusion" action [[form]] from the list of actions, 
information identifying the action selected is sent to the second central server 108a. In response, 
the second central server 108a causes the digital assistant 1 18 to display a screen prompting the 
user to scan a machine-readable identifier associated with the medication 124 to be resumed at 
block 6106. An example of a digital assistant display 1 18a prompting the user to scan a machine- 
readable identifier associated with the medication 124 is illustrated in FIGURE 34. The user may 
use the scanner of the digital assistant 118 to scan the medication label 124a on a bag of 
medication 124 (e.g., a barcode on an infusion bag). Alternatively, the user may manually enter 
the medication identifier into the digital assistant 118. 

On page 1 18 of the specification, please replace the paragraph beginning at line 29 with 
the following paragraph: 

If the infusion is resumed at block 6134, the first central server 109 returns a success code 
to the second central server 108a via the completion URL at block 6144. The first central server 
109 maintains the association between the patient identifier, the medication identifier, and the 
channel identifier for the selected infusion . The second central server 108a only updates the 
status of the infusion to "running" upon receiving a success code from the first central server 109. 
Any other result (e.g., cancel code or failure code) causes the second central server 108a to keep 
the infusion in its previous state. Preferably, if the user wants to resume both a primary infusion 
and a piggyback infusion running on a channel, the user may execute the "resume infusion" 
action twice, once for each infusion. The Resume process may be utilized t document that the 
infusion was restarted for purposes of the MAR. 

On page 1 19 of the specification, please replace the paragraph beginning at line 32 with 
the following paragraph: 

When the user selects the "remove pump" action [[form]] from the list of actions, 
information identifying the action selected is sent to the second central server 108a. In response, 
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the second central server 108a causes the digital assistant 1 18 to display a screen prompting the 
user to scan a machine-readable identifier associated with the medication 124 to be affected by 
this "remove pump" action at block 6206. An example of a digital assistant display 118a 
prompting the user to scan a machine-readable identifier associated with the medication 124 is 
illustrated in FIGURE 34. The user may use the scanner of the digital assistant 1 18 to scan the 
medication label 124a on a bag of medication 124 (e.g., a barcode on an infusion bag). 
Alternatively, the user may manually enter the medication identifier into the digital assistant 118. 

On page 124 of the specification, please replace the paragraph beginning at line 15 with 
the following paragraph: 

The digital assistant 118 uses the first central server's digital certificate to authenticate the 
first central server 109 at block 6410. In addition, at block 6412 the digital assistant 1 18 uses the 
first central server's digital certificate to retrieve an embedded uniform resource locator (URL) 
associated with the first central server 109. The digital assistant 118 can now request data and 
services [[form]] from the retrieved URL knowing it is talking to the real first central server 109. 

On page 127 of the specification, please replace the paragraph beginning at line 1 with the 
following paragraph: 

The medical device 120 uses the first central server's digital certificate to authenticate the 
first central server 109 at block 6714. In addition, at block 6716 the medical device 120 uses the 
first central server's digital certificate to retrieve an embedded uniform resource locator (URL) 
associated with the first central server 109. The medical device 120 can now request data and 
services [[form]] from the retrieved URL knowing it is talking to the real first central server 109. 



